The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props extrachill, westonruter.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

Related:

• Connectors: preload REST API responses on the Connectors screen gutenberg#77353

I can see that this is successfully eliminating 4 client-side REST API requests:

Before	After

Is there an opportunity to preload more?

I think there is a strong chance the answer is yes. I will run some more tests and see what I can do. Appreciate your feedback.

Thanks for asking whether there was room to preload more. I did a focused sweep of the remaining visible REST requests using the Homeboy Site Editor benchmark rig and REST waterfall diff tooling.

What changed in the latest push:

• Added GET /wp/v2/types/post?context=edit when the resolved initial template contains a Query Loop.
• Added the edit-context page tree request: GET /wp/v2/pages?context=edit&per_page=100&_fields=id,link,menu_order,parent,title,type&orderby=menu_order&order=asc.

Validated scenarios, with the extra route set matching the actual patch behavior (types/post only for Query Loop templates):

The earlier 3-iteration default run with both added routes also reduced the full REST waterfall from 34 requests / 19 unique to 20 requests / 12 unique while keeping the measured canvas phase at 0 REST resources. That run averaged 1209ms -> 894ms, a -316ms / -26.0% delta.

I tested other visible routes too, but did not add them:

• GET /wp-block-editor/v1/navigation-fallback?_embed=true removed its target request, but reintroduced measured resources and slowed readiness.
• GET /wp/v2/users/me?context=edit, GET /wp/v2/pages?context=view..., GET /wp/v2/menus?..., and GET /wp/v2/wp_pattern_category?... did not remove their target requests in this scenario.

Tooling used:

• Homeboy Site Editor preload comparison rig: Report Site Editor REST preload waterfalls chubes4/homeboy-rigs#113
• REST waterfall comparison/reporting helpers: wordpress: report REST network diffs Extra-Chill/homeboy-extensions#575

Validation run locally:

• php -l src/wp-admin/site-editor.php
• ./vendor/bin/phpcs -s --standard=phpcs.xml.dist src/wp-admin/site-editor.php
• ./vendor/bin/phpcs -s --standard=phpcompat.xml.dist src/wp-admin/site-editor.php
• homeboy lint --path /Users/chubes/Developer/wordpress-develop@fix-site-editor-preload-canvas-data --extension nodejs
• homeboy test ... got through build and QUnit (456 tests, 0 failures), then stopped at local PHPUnit setup because wp-tests-config.php is not configured.

Opening the Home template in the Site Editor is now down to 15 client-side fetches instead of 20:

Before	After

LFG! 🚀

Out of curiosity, I tired preloading all REST API requests for my homepage template in the Site Editor:

$preload_paths[] = '/wp/v2/templates/twentytwentyfive//home?context=edit';
$preload_paths[] = '/wp/v2/wp_pattern_category?context=view&per_page=100&_fields=id%2Cname%2Cdescription%2Cslug';
$preload_paths[] = '/wp/v2/block-patterns/patterns';
$preload_paths[] = '/wp/v2/taxonomies?context=edit&per_page=100';
$preload_paths[] = '/wp/v2/menus?context=view&per_page=100';
$preload_paths[] = '/wp/v2/pages?context=view&parent=0&order=asc&orderby=id&per_page=100';
$preload_paths[] = '/wp/v2/navigation/274?context=edit';
$preload_paths[] = '/wp/v2/pages/82?context=edit';
$preload_paths[] = '/wp/v2/pages/84?context=edit';
$preload_paths[] = '/wp/v2/pages/2?context=edit';
$preload_paths[] = array( '/wp/v2/settings', 'OPTIONS' );
$preload_paths[] = array( '/wp/v2/templates/twentytwentyfive//home', 'OPTIONS' );
$preload_paths[] = array( '/wp/v2/templates', 'OPTIONS' );
$preload_paths[] = array( '/wp/v2/navigation', 'OPTIONS' );
$preload_paths[] = array( '/wp/v2/navigation/274', 'OPTIONS' );

I couldn't get these to get preloaded:

Was there a measurable impact on speed? The test runs I did found that some of the requests actually slowed down the overall load time when preloaded. There's a chance the harness was flawed in some way.

Do you think the 6 requests that you couldn't get preloaded might point to something deeper worth investigating?

This benchmark tooling is so fun to use, I'm happy to keep poking at things to see how fast we can make it without regressions.

Well, I couldn't get all of them to be preloaded so I didn't go that far to measure. I was going to try measuring after all of the requests were preloaded. But if requests aren't in the critical rendering path, then indeed it doesn't make sense to preload since then it just slows down the page from being served.

Follow-up from the remaining visible REST rows in DevTools: I traced the preloading middleware keys and caller stacks in Gutenberg, and the duplicate OPTIONS rows are separate client-side follow-ups rather than missing server preload declarations in this backport.

Tracked Gutenberg issues:

• core-data: root site OPTIONS response is not reused for canUser permissions gutenberg#78259: OPTIONS /wp/v2/settings is fetched once for root site entity schema loading and later again by canUser( ..., { kind: 'root', name: 'site' } ) instead of reusing the first response's Allow header.
• core-data: id-less entity resources can duplicate canUser OPTIONS requests gutenberg#78260: OPTIONS /wp/v2/navigation can be requested twice for the same id-less navigation collection permission because resolver args are not normalized/deduped before the first preload entry is consumed.

One diagnostics detail worth preserving: DevTools shows the post-middleware URL with _locale=user, while createPreloadingMiddleware() checks the pre-locale key first. For example, /wp/v2/taxonomies?context=view is the correct preload declaration even when the visible network row is /wp/v2/taxonomies?_locale=user&context=view.

That means this PR/backport should stay focused on predictable server-side Site Editor preload declarations. The remaining duplicate OPTIONS behavior belongs in the linked core-data issues rather than broadening this patch just to chase a zero-request waterfall.

@westonruter Your experiments helped expose two upstream bugs:

• Core Data: Avoid duplicate id-less entity permission requests gutenberg#78262
• Core Data: Reuse site settings permissions gutenberg#78264